The Windows Azure Tool Set

1. Getting and Installing the Tools

You can use the following two primary tools to develop for Windows Azure:

• Windows Azure Software Development Kit (SDK)

• Windows Azure Tools for Visual Studio (which is bundled with the SDK as well)

The Windows Azure SDK is a free download that contains CSPack (used for packaging your applications), the Development Fabric, and other essential tools needed for building applications for Windows Azure. (You’ll learn what these tools do later in this chapter.) The SDK typically has a new version released every few months. You can find a link to the latest SDK download at http://www.microsoft.com/azure.

The Windows Azure Tools for Visual Studio (referred to simply as the “Visual Studio tools” throughout this book) are bundled with the SDK and plug into Visual Studio to make development against the SDK easier. The biggest add-on that the Visual Studio tools provide is a set of Visual Studio project templates, as well as the ability to debug locally.

2. Satisfying the Prerequisites

Before installing the SDK and the Visual Studio tools, you must ensure that you have installed several prerequisites on your machine. You must have at least Windows Vista SP1 and .NET Framework 3.5 SP1 installed. IIS 7 with ASP.NET is required to run your cloud services on your local machine, and Windows Communication Foundation (WCF) HTTP Activation must be turned on. The SDK installs a mock version of the storage services in the cloud meant for local development. You’ll need SQL Server (either the full-blown version or the Express edition) installed to make that work.

Installing these prerequisites separately can be a hassle. One easy way to install all of them with one tool is through the Microsoft Web Platform installer, available from http://www.microsoft.com/web. Figure 1 shows the Web Platform installer with the Windows Azure tools (an early version) set to be installed. Note how the necessary dependencies are detected and installed.

3. Getting to Know the SDK and Tools

If everything installed correctly, you should see a variety of new items in your Start menu, as shown in Figure 2. (Note that this figure is reproduced from an early build of the software, and you’ll almost surely see a different icon.)

To make it easier to use the tools that come with the SDK as this discussion progresses, let’s take a brief look at what you get when you install the SDK:

Documentation

Like all good SDKs, you get the latest documentation corresponding to the release. Apart from the .chm files, there are readme files scattered throughout the samples.

---

Note: The documentation is mirrored on the MSDN website, and you’re probably better off looking at the online versions because any changes/additions are instantly reflected there.

---

CSPack

This is arguably the most important binary shipping in the SDK. Cspack.exe enables you to package up your application into a format that Windows Azure can understand and run. Whether you call this binary directly, or whether it is called for you by a tool (such as Visual Studio), this is what you use to package up your services.

---

Note: You’ll see a lot of tools/file extensions starting with the letters CS in Windows Azure. The letters stand for “Cloud Service.” The actual acronym to use was picked close to the date of Windows Azure’s initial launch, and there was a bit of discussion on the exact extension to use. One contender was the letters UC (for “Utility Computing”), which you can find in other parts of early SDKs.

---

Development Fabric and Development Storage

These provide a simulated version of Windows Azure to help you develop code on your own machine, and test it before deploying against the actual cloud. We examine both of these in greater detail later in this chapter.

Samples

The SDK ships with the obligatory samples, as well as some useful tools masquerading as samples. You’ll learn how to use some of these tools throughout the book.

---

Note: As of this writing, some of these samples were being moved out of the SDK and onto http://code.msdn.microsoft.com/windowsazuresamples. If you can’t find some of the samples referenced, check that URL.An easy way to access all the tools that come with the SDK is through the setenv.cmd batch file in the bin folder of the SDK. This can also be accessed through the Windows Azure SDK Command Prompt option on the Start menu. This brings all the right folders into your environment PATH, and sets up some environment variables required for these tools to work.

---

Project templates and debugging

Though it is possible to fully complete your development without Visual Studio at all, you’ll save yourself a ton of effort by using the integrated support for the SDK in Visual Studio. The biggest value-adds in Visual Studio are the presence of project templates corresponding to the different ways in which you can package your application, as well as debugging support for you to locally debug your application.

4. Understanding the Development Fabric

When you’re developing for an environment that is very different from your desktop computer, it really helps to have a local simulator/emulator/mock interface to help you develop. For example, most mobile platforms include a simulator that runs on normal machines and attempts to simulate a mobile phone with high fidelity. ASP.NET developers are familiar with Cassini, the local development web server that ships with Visual Studio. The same need for a local simulator holds true for the cloud as well.

On the actual cloud, your code runs on different virtual and physical machines. Since launching a virtual machine on a normal physical (development) machine requires a lot of overhead, the Development Fabric (Dev Fabric) launches different processes instead. For every virtual machine you’ll see launched in the cloud, the Dev Fabric launches a local process called RdRoleHost.exe to host your application. Since these are just normal processes, you can attach a debugger to them, and perform typical debugging tasks (such as setting breakpoints, inspecting and changing values, stepping through code, and so on). In fact, this is how the Visual Studio extensions provide debugging support; they attach to the processes launched by the Dev Fabric.

Figure 3 shows the Dev Fabric providing a simulation of the Windows Azure fabric on a local machine. In short, the Dev Fabric enables a developer to build, debug, and test code locally before deploying to the actual cloud.

You can launch the Dev Fabric from the Start menu item installed by the SDK, or through the CSRun tool (which you’ll learn about shortly). The Dev Fabric is rarely launched directly; most developers simply use the integrated Visual Studio support, and have Visual Studio launch it for them.

4.1. Differentiating between the cloud and the Dev Fabric

Though the Dev Fabric tries to provide as accurate a simulation of the cloud as possible, there are some fundamental differences between running code on your local machine and running code on the cloud. Following are some “gotchas” that sometimes trip up developers when they find that code works on the cloud but does not work on the Dev Fabric (or vice versa):

• The Dev Fabric uses processes to simulate virtual machines. If your package is configured to run on five different virtual machines, it’ll run on five different processes on your local machine. This can lead to some quirky performance differences. For example, a misbehaving process can affect other processes locally, but a misbehaving virtual machine will not.

• The Dev Fabric doesn’t check for code that can’t run on the cloud, nor does it ensure that you don’t use something that doesn’t exist on the cloud. For example, if you try to use a registry key/file/COM component that exists on your local machine, it’ll work on the Dev Fabric, but will fail on the cloud if it doesn’t exist there as well.

• The Dev Fabric runs on the same architecture as your local machine’s operating system. If you have an x86 operating system, the Dev Fabric will run in x86 mode. However, in the actual cloud, all code is 64-bit, so you might run into issues moving from x86 to x64. This difference becomes critical when running native binaries.

• Since the Dev Fabric is running on your local machine, network performance is very different from what you’ll experience in the cloud. This difference is especially noticeable when talking to other Windows Azure services (such as the Windows Azure storage services). When your code is running in the cloud, network latency is reduced because of other services being in the same data center. When your code is running on your local machine, it takes longer to access storage services in a Microsoft data center. Note that, in the case of storage, you can use the Development Storage (which you’ll learn about shortly) on your local machine.

• You shouldn’t use the Dev Fabric to get an accurate sense of performance. Since the Dev Fabric is just another process on your local machine, performance will vary based on your machine’s hardware. Unless your machine is a 1:1 match to the virtual machine in the cloud in terms of resources (highly unlikely), you’ll notice a significant difference in performance.

5. Development Storage

While the Dev Fabric simulates the Windows Azure fabric and is used for hosting code, the Development Storage (Dev Storage) part of the SDK is used to simulate the Windows Azure storage services—blobs, tables, and queues. It does this by using a local SQL Server instance as a backing store, and providing a local running instance of the Windows Azure blobs, tables, and queues.